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Abstract — The transition to new technology, innovative ideas, 
and resistance to change is something that every industry 
experiences. Recent examples of this shift are changing to using 
robots in the assembly tine construction of automobiles or the 
increasing use of robotics for medical procedures. Most often this is 
done with cost-reduction in mind, though ease of use for the 
customer is also a driver. All industries experience the push to 
increase efficiency of their systems; National Aeronautics and 
Space Administration (NASA) and the commercial space industry 
are no different. NASA space communication services are provided 
by three separately designed, developed, maintained, and operated 
communications networks known as the Deep Space Network 
(DSN), Near Earth Network (NEN) and Space Network (SN). The 
Space Communications and Navigation (SCaN) Program is 
pursuing integration of these networks and has performed a variety 
of architecture trade studies to determine what integration options 
would be the most effective in achieving a unified user mission 
support organization, and increase the use of common operational 
equipment and processes. 

The integration of multiple, legacy organizations and existing 
systems has challenges ranging from technical to cultural. The 
existing networks are the progeny of the very first communication 
and tracking capabilities implemented by NASA and the Jet 
Propulsion Laboratory (JPL) more than SO years ago and have 
been customized to the needs of their respective user mission base. 
The technical challenges to integrating the networks are many, 
though not impossible to overcome. The three distinct networks 
provide the same types of services, with customizable data rates, 
bandwidth, frequencies, and so forth. The differences across the 
networks have occurred in effort to satisfy their user missions’ 
needs. Each new requirement has made the networks more unique 
and harder to integrate. The cultural challenges, however, have 
proven to be a significant obstacle for integration. Over the past few 
decades of use, user missions and network personnel alike have 
grown accustomed to the processes by which services are provided 
by the NASA communications and navigation networks. The 
culture established by each network has created several challenges 
that need to be overcome in order to effectively integrate the 
networks. As with any change, there has been resistance, an 
apprehension to explore automation of existing processes, and a 
working environment that attempts to indirectly influence change 
without mandating compliance. Overcoming technical and cultural 
challenges is essential to successfully integrating the networks and 
although the challenges are numerous, the integration of the 
networks promises a more efficient space communications network 
for NASA and its customers, as well as potential long-term cost 
savings to the agency. 
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This paper, Challenges of Integrating NASA Legacy 
Communications Networks, will provide a brief overview of the 
current NASA space communications networks as well as the an 
overview of the process implemented while performing the SCaN 
Trade Studies and an introduction to the requirements driving 
integration of the SCaN Networks. This paper will describe in detail 
the challenges experienced, both technical and cultural, while 
working with NASA space communications network-specific 
personnel. The paper will also cover lessons learned during the 
performance of architecture trade studies and provide 
recommendations for ways to improve the process. 
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I. Space Communications and Navigation Program 

A. Today’s space communication and navigation networks 

The SCaN Network is currently divided into three unique 
space communication networks; the DSN, NEN, and the SN. 
Though each of the networks provides communication services 
to user missions, they have distinct systems and processes by 
which services are provided. The services provided are based 
on their respective user mission community needs. 

The SN consists of a constellation of geosynchronous 
relays (Tracking and Data Relay Satellites (TDRS)) and 
associated ground systems [1], Mission supported range in 
location from earth based to geosynchronous orbits, including 
suborbital missions. The integration of the networks may result 
in more use of the TDRS satellites by the user mission 
communities of the other networks as well. The software 
systems utilized by the SN were initially developed in the 
1980’s. Over the years, many changes have been made. The 
SN has recognized the need to increase the efficiency of the 
services they provide to the users and has begun a 
modernization and recapitalization project to completely 
renovate the hardware and software systems. The “integration 
readiness” of the SN relies heavily on the completion of the 
system updates. 

The NEN consists of NASA, commercial, and partner 
ground stations and integration systems providing space 
communications and tracking services to lunar, orbital and 
suborbital missions [1], In some ways the NEN is an example 
of integration in action; as services provided by NASA, 


commercial and partner ground stations are all planned by 
interacting with Network Integration Management Office 
(NIMO), and requested, and scheduled via a single NEN 
system. This network utilizes software that is monolithic by 
design and highly customized which may result in extra work 
by the software vendor to adapt the NEN software for 
integration. The NEN is comprised of several ground terminals 
which utilize dissimilar equipment from one another, thus 
making integration of process increasingly difficult. 

The DSN consists of large aperture ground stations located 
around the world providing coverage of spacecraft from 
Geosynchronous Earth Orbit (GEO) to the edge of our solar 
system [1]. This network provides their user missions with a 
collaborative scheduling environment through which the user 
missions can collaborate with each other to schedule time on 
the DSN ground terminals. The DSN operational process 
requires the most manual operation of any of the three 
networks. The lack of automation in the operational process 
requires DSN operators to intervene and/or confirm the 
execution of services at different points in order for the process 
to proceed. 

The three networks provide a variety of communications 
and navigation services to user missions. In order to access 
these services, user missions go through a service planning 
process. This process enables them to enter into a service 
agreement with NASA to provide user mission-specific 
communications and/or navigation services to the user mission. 
The service planning process is different between the networks. 
The SN and NEN user missions work with the NIMO to 
facilitate the planning of their mission, while DSN user 
missions work with the DSN Mission Services Planning & 
Management (DMSP&M) Office to fulfill their planning 
needs. These two organizations provide roughly the same 
services, though they implement these services through 
different processes. Integration will allow the implementation 
of common processes. 

Most science user missions have very specific 
communication and navigation requirements which allow them 
to work with only one or occasionally two of the SCaN 
Networks. Often times the second network is requested to 
provide backup services in case of a network issue or user 
mission emergency situation that requires rescheduling or 
reallocation of network resources. To meet the various 
communications requirements of human space flight missions, 
all three of the SCaN Networks must be utilized. Integration 
resulting in a single process to acquire services from all three 
SCaN Networks would significantly reduce the level of effort 
exerted by human space flight missions to meet space 
communication and navigation requirements. 

This is a general description of today’s space 
communication networks. Each network has a different 
assortment of user mission’s utilizing the provided services. 
Though the networks differ in many ways, they are all an 
integral part of the way SCaN communications and navigation 
services are provided today and in the future. Integrating the 
networks to minimize unnecessary differences between the 
networks may help to reduce user mission burden and cost to 
NASA and the user mission in the long run. Fig. 1 shows the 


integrated network architecture concept that is the goal of the 
SCaN Network Integration Project (SNIP). 



Fig. 1 . SCaN Integrated Network Architecture 
B. Integration Goals 

The integration of NASA’s communication and navigation 
capabilities began in the summer of 2006, when the NASA 
assigned management and Systems Engineering and 
Integration (SE&I) responsibilities for the Agency’s space 
communications and navigation assets to the SCaN Office and 
directed the centralized management of NASA’s space 
communications and navigation networks. The push for 
integration was formalized further by a Program Commitment 
Agreement (PCA) in 2009 that reiterated the SCaN Program’s 
responsibility for providing communications and navigation 
services (including systems engineering and planning) to user 
missions, and maintaining and evolving the SCaN architecture 
to effectively and efficiently meet user missions' present and 
future needs. The PCA included seven objectives which have 
become the SCaN Program’s driving requirements. The first 
of these driving requirements mandates the development of a 
unified space communications and navigation network 
infrastructure that meets both robotic and human exploration 
mission needs [2]. The remaining driving requirements could 
be enabled through unification if it resulted in the pooling of 
both technological and financial resources. 

What this unified network might look like and what 
integration or unification means has been the subject of many 
debates and discussions within the NASA space 

communications and navigation community. The trade study 
team proposed that unification or integration would be 
achieved when there was an increase in common hardware, 
software and processes across the three existing SCaN 
Networks. The goal of integration is limited by the fact that 
some technological and process differences exist to meet user 
mission requirements. 

In order to define the future vision in a quantitative manner, 
multiple architecture and commonality trade studies have been 


performed. Through the performance of these studies two 
themes have become clear, any efforts towards integration 
should increase the ease in which the user missions interact 
with SCaN and these changes must not inhibit the ability of 
SCaN to provide the variety of communications and 
navigations services desired by the user missions. Studies on 
the interactions between SCaN and user missions, such as the 
Service Planning Commonality Study focused on early user 
interaction with SCaN, and brought to light the difficulty new 
user missions experience in learning about SCaN services and 
obtaining these services. Changes in processes and tools were 
identified as ways to improve the working relationship between 
SCaN and user missions. 

The quantification of this need and guidance on how to 
address it resulted in the creation of the SNIP which will be 
responsible for implementing, in a step wise manner, projects 
resulting in the integration of the SCaN Networks. 

In parallel with the performance of trade studies, the 
individual space communications networks have been 
implementing multiple, different recapitalization projects to 
ensure they can continue to meet their individual user mission 
needs while integration efforts are being defined. The largest of 
these projects is the SN Ground Systems Sustainment (SGSS) 
Project. This project will modernize the ground segment to 
enable the SN to continue to deliver high quality services, meet 
stakeholder requirements, and significantly reduce required 
operations and maintenance resources [3]. The parallel 
performance of these recapitalization projects has presented 
both challenges and benefits to the integration efforts. 

C. Trade Studies Processes 

Trade studies provide an objective foundation for selecting 
one of two or more alternative approaches to solve an 
engineering problem and support decisions in all stages of 
system development, from conceptualization to deployment 
[4]. Trade studies can be used to determine the optimum of 
many technical options within a given trade space. In this case, 
numerous architecture options were developed and then 
evaluated using a systematic process. 

The trade study team consisted of systems engineers and 
from Glenn Research Center, Goddard Space Flight Center, 
and JPL as well as subject matter experts from each of the 
three SCaN Networks. The first step in the process was the 
identification of the boundaries of the trade space under 
examination. Next, brainstorming of potential architecture 
solutions within that trade space took place. The various 
options were considered by team members to ensure there was 
value and no inhibiting factors that would prevent the eventual 
implementation of a particular option. Cost was analyzed 
during these steps, but was not used as a factor for elimination 
of any particular option. 

To ensure complete understanding of the existing network 
architectures and to capture their similarities and differences, 
both system architecture and operational processes were 
modeled within the predefined trade space. This was the first 
time SCaN had implemented Model Based Systems 
Engineering (MBSE) practices. The learning curve experienced 
during this effort paid off immensely because it allowed the 


study team to create detailed system architecture and 
operational processes for the architecture options under 
consideration. The modeling effort facilitated the comparison 
of both existing architectures and proposed architectures to 
determine where the technical challenges in implementation 
may arise, as well as facilitating the estimation of 
implementation and operational costs associated with each 
proposed architecture option. 

A risk assessment evaluation was performed to determine 
which, if any, architecture options should not be considered 
because of the level of risk associated with them. 

Figures Of Merit (FOM) were developed to enable the 
quantitative evaluation of the value of each architecture and 
operational process option. The FOMs were developed in a 
way which minimized the potential skewing of the results 
towards one option or another whenever possible. Finally, 
trade study conclusions were presented to a review board for 
evaluation and feedback before the final conclusions were 
presented to the SCaN Program Management team and 
managers from the SCaN Networks. 

II. Integration Challenges 

Many challenges stand in the way of integrating the three 
SCaN networks into one integrated network. While none of the 
technical challenges are “show stoppers” for the integration, 
they make the integration effort more difficult. Cultural 
challenges on the other hand could delay or even prohibit 
integration if not overcome. 

A. Difficulties presented by legacy systems 

The software liability in each of the networks is a technical 
challenge. Of the three networks, the DSN uses the most 
current code techniques and languages which can lead to 
increased scalability and extensibility. The SN and NEN, on 
the other hand, use some older software techniques that can 
cause problems when attempting to integrate the software into 
a system using the latest software techniques. Over the years 
since its initial implementation in the 1980’s, the SN software 
system has been reworked many times to solve issues, bugs, 
apply patches, etc. The patches and code fixes were only meant 
to be a temporary solution. These numerous software fixes also 
make it increasingly more difficult for new developers to come 
up to speed on the software system of the SN, which could lead 
to increased integration timeframes. Addressing this issue is a 
primary focus of SGSS. 

The NEN software system is using some older code 
languages and techniques, much like the SN. The NEN has the 
further problem of being monolithic by design. This monolithic 
software could lead to difficulty when integration starts as a 
small change in the code may result in major changes 
elsewhere. A more modular software design would allow for 
changes to be applied to particular system while not impacting 
the systems which interface to it. 

Of all of the networks, the DSN uses the most current 
software languages and techniques to implement its 
functionality. The recently renovated Service Scheduling 
Software (SSS), which was developed using modern 



development paradigms, provides the schedule de-confliction, 
schedule generation, etc. for the system. The SGSS software 
includes a scheduling system for the SN which may be the 
baseline for the integrated scheduling system. If so, that 
software may need to be extended to interface with SSS, or 
SSS will need to be replaced. Due to the currency of the SSS 
software, however, this should be a relatively painless task. 

Over time the SCaN networks have become customized 
based on user mission requirements. Without a standard set of 
services that a user mission must choose from to acquire 
service, user missions have occasionally directed the networks 
to provide them whatever services the user mission deems 
necessary to enable the mission, even if most of the cost of 
upgrades to the network become the responsibility of the SCaN 
Program instead of the user mission. As discussed earlier, each 
network has a different user mission community based on the 
characteristics and capabilities of the network. As a result, the 
SCaN networks have become overly responsive to the needs of 
their user mission customers. The networks continually 
become less similar with every specialized service, equipment, 
and software code that is introduced into the system to meet 
user mission needs. 

Although the differences in current software 
implementation do not directly impact whether or not the 
systems can be integrated, these challenges do impact the 
design of the integrated system. Systems and operational 
process options under consideration were occasionally 
modified as maintenance and sustainability challenges were 
identified to ensure a higher level of maintainability and 
sustainability within the future SCaN Network. 

B. Current Technical Challenges 

For the reasons listed above, as well as others, each of the 
networks has realized the need for modernizing or 
recapitalization of their processes, software, hardware, and 
operations. The SN has contracted an upgrade for their 
network, SGSS, which will modernize all aspects of the 
network. This includes brand new software and hardware 
systems. The operational and maintenance processes will also 
change due to the changes to the other systems. In fact, an 
additional goal of SGSS is a significant reduction in the system 
maintenance required. NEN has considered an upgrade to their 
monolithic system but due to budget constraints has not been 
able to modernize the network. The DSN has taken steps to 
upgrade their network as well. As discussed previously, DSN 
has built a scheduling software front-end for the new 
scheduling system that JPL developers have coded. The DSN 
is also in the process of upgrading several of the antennas at 
their ground station sites. While each of these modernization 
attempts is a step in the right direction for each network, the 
on-going changes make it more difficult to develop a process 
for the integration to occur. Integration process steps need to be 
developed for implementation, but the step design becomes 
more difficult to capture because both the existing and 
modernized implementations (which are still being designed) 
must be understood. The considerable amount of money spent 
on the SGSS upgrade has motivated SCaN to analyze how 
much of the SGSS upgrade to SN can be adapted to the NEN 
and DSN. The differences in the types of user missions 


supported and recent, independent upgrades to the DSN make 
the adaptation of SGSS difficult but not impossible. SGSS 
hardware and software at ground station sites cannot be used 
“as-is” for DSN and NEN ground station sites and so 
modifications of the software, and possibly hardware, will need 
to take place. This adaptation for the DSN and NEN has been 
a focus of the trade study efforts. The trade study has 
determined that the software and hardware from SGSS can be 
adapted to interface with DSN and NEN hardware and 
software. Though these adaptations will require further work 
from the release state, they are not a deal-breaker to the 
integration effort. The operational processes will also have to 
change due to the high level of automation SGSS provides for 
functions such as scheduling, planning, network asset 
assignment, etc. 

These are only a handful of the technical challenges that 
must be faced in the integration of the legacy SCaN networks 
into a more integrated network. The networks have many 
different technical characteristics that need to be analyzed 
before any implementation can occur. Though these technical 
challenges do produce some difficulty for the SCaN integration 
effort, the technical challenges are much easier to overcome 
than the cultural differences between the networks and the 
challenges they create. 

C. Cultural Challenges 

Though there are many technical challenges to consider 
when integrating the three SCaN networks, the cultural 
challenges are equally difficult to resolve. Cultural differences 
between the networks have occurred over time as a result of the 
networks “growing up” separately. Separate user mission 
communities, different management philosophies, different 
software systems, and ability to adapt to a changing technical 
world are all contributing factors to existence of cultural 
differences between the networks. 

When attempts to integrate similar legacy systems which 
were developed independently are made it is common to 
discover processes and modes of operation which serve the 
same purposes differently. Occasionally the differences are 
small and integration into a common process is easy, often 
times because the processes are well tailored to existing 
operations changing to a common process is unwelcome. The 
following are examples of network specific processes which 
have similar intents but different implementations. 

As discussed earlier, the scheduling systems between the 
SCaN networks are fundamentally different. The scheduling 
system for the SN and the NEN use a priority-based scheduling 
system to determine where a user mission’s access to 
scheduled services. If two user missions were to schedule the 
same service at the same time, then the user mission with the 
higher mission priority is scheduled. Mission priority is used to 
prioritize user missions. This is different than “absolute” 
priority (emergencies, critical events) which takes priority over 
mission priority. The DSN, on the other hand, uses a 
collaborative scheduling system for conflict resolution. If two 
user missions schedule the same service at the same timeframe, 
the SSS scheduling system contacts all user missions to inform 
them of the conflict. It is then up to the user missions to work 



together to negotiate how their services can be scheduled at a 
time that satisfies each of their requirements. 

The user mission community of the DSN has always used 
this collaborative scheduling system and is understandably 
concerned with a possible shift to a priority scheduling system. 
A priority-based system could eliminate or reduce the hands-on 
collaboration this user mission base has developed in favor of 
making the scheduling process more time efficient. Integration 
into a single scheduling system may be a part of the integration 
of the SCaN networks. It will be the responsibility of each 
network to transition their user missions to the new scheduling 
system. Transitioning user missions to new systems, new 
processes, and standard services is a key challenge facing 
SCaN. 

As previously discussed, automation plays a big role in the 
differences between the SCaN networks. DSN has a very user 
mission, hands-on scheduling process currently. NEN has a 
service execution process which involves operators setting-up 
control tables which correspond to equipment configurations to 
enable user mission services. The planning processes for each 
of the three networks are almost completely manual processes 
which require considerable documents, emails, phone calls, 
contacts, etc. Each network has areas where automation could 
help to further the efficiency of the network for the user 
mission. By increasing automation in the networks (throughout 
the mission lifecycle) it is anticipated that user missions can 
expect shorter turnaround times from service planning to 
service execution, the SCaN network can expect reduced costs 
from lowered personnel counts as well as labor hours, and the 
SCaN operators can focus on addressing emergent issues and 
emergencies, as opposed to nominal operations. The difficulty 
lies in the resistance to updating the networks to accommodate 
such a level of automation. Concepts such as utilizing 
automation to enable network operators to handle additional 
communications links or to minimize network operator 
intervention in the operations process have initially met with 
resistance. However, after further analysis during the trade 
studies, it has been found that efficiency can be gained through 
automation of the operational processes, and the resistance has 
softened. Whether the operator has to push a button to forward 
a process along to the next step or the software intelligence 
checks all parameters and approves the promotion itself, is up 
to the networks but one is clearly more advantageous as far as 
cost and efficiency is concerned. 

Some of the same arguments can be applied to the service 
planning process, as briefly mentioned above. The processes 
used by NIMO and DMSP&M are almost completely manual. 
The personnel in those organizations work with the user 
missions to determine the correct mission parameters to 
acquire service. The process results in the signing of several 
documents including a Service Level Agreement, a Network 
Operations Plan, Interface Control Documents, and others. 
These documents are similar but not the same between the two 
planning offices and thus the processes and information 
required from the user mission is slightly different. If a user 
mission requires service from more than one network, then 
currently, the user mission must work with both planning 
offices, and follow separate processes. 


A potential approach to integrate these processes is the 
creation of a Service Planning portal, which was 
rrecommended by the trade studies. This portal would enable 
the user missions to access only one website and begin their 
planning process. The portal would enable the user mission to 
enter mission requirements and other mission parameters 
electronically into the system to establish the necessary 
documentation. The back-end portal system would generate the 
necessary documentation from the information the user mission 
has entered. While this portal does not necessarily demand the 
integration of the two planning offices, naturally that 
integration would create a more efficient process, and from the 
perspective of the user missions, there appears to be a single 
point of contact. 

The portal concept and design has not been without 
difficulty. The two planning offices have been joined into one 
overarching planning office called the Mission Commitment 
Office. To date, only marginal progress has been made to 
harmonize the planning documentation at each office. 
Obviously the increased automation of the planning process 
and the merger into one planning office, from two, should 
result in savings to the SCaN network from a reduction in 
personnel costs. It should also decrease the burden placed on 
the user missions who wish to acquire SCaN services from 
multiple networks. 

During the trade studies, the network control operations, at 
each network, were studied by the team. Network cross- 
support was an option that the team looked out. As used in this 
context, cross-support means that an operator from the SN 
would temporarily be assigned operational duties on the NEN, 
for example. This would require the operator to be aware of the 
operational processes of each of the networks. Currently the 
operators are trained on the operational process of the network 
for which they are assigned. The rigorous training process 
takes anywhere from six months to two years to properly train 
a new operator. Upon further analysis, a generational 
difference emerged. Some hold the opinion that no operator is 
capable of operating more than one network; the networks are 
simply too complicated. Others hold the opinion that given the 
current integration rate of technology into everyone’s lives, 
from a very young age, provided the appropriate level of 
automation, one operator may be able to operate multiple 
networks. Multi-tasking has become the nominal mode of 
operation for employees of all industries. More and more 
business includes international contact which means the 
employees are required to be fluent in several languages. 
Software developers are required to know several development 
languages in order to meet user mission needs. The younger 
generation is more equipped to handle multiple and diverse 
operational procedures and languages; they have been doing it 
their whole lives. This makes the younger generation more 
capable of handling the training and operational processes that 
are required to enable network operator cross-support. SCaN, 
like any other organization, needs to adapt to its changing 
environment and changing workforce in order to capitalize on 
the strengths that exist within the up and coming generation of 
employees. 

In order to socialize proposed changes within the networks 
progress reviews with SCaN Network managers and SCaN 



Program management were held periodically. These reviews 
helped inform the persons responsible for maintaining and 
operating the existing networks to understand what options had 
been considered and which ones were being proposed as part 
of the architecture of the future SCaN Network. Not 
surprisingly these reviews presented challenges in that 
whenever a new or innovative idea was presented it was 
predictably met by resistance. 

A final, and overarching, cultural challenge within the 
integration process has been the resistance to new ideas. There 
is a familiarity to “the way things have always been done”; the 
future and the changes it brings can be unsettling to some. The 
initial reaction to new integration approaches were often met 
with opposition. However, often, after discussion and analysis, 
those initially opposed would either retract their opposition or 
acknowledge that some of the new ideas proposed were 
possible. Not all of the integration ideas proposed were 
technically feasible, as proven during further study, but an 
initial opposition to new and innovative ideas seems to be 
prevalent. The opposition appears to be the result of ensuring a 
high-degree of user mission focus, and pride in a history of 
meeting and exceeding user mission expectations. Regardless, 
if SCaN desires to provide their user missions with the highest 
quality and most efficient service processes, than new ideas 
need to be encouraged and then openly considered. 

III. Lessons Learned 

Many different challenges, both technical and cultural were 
experienced during the course of the trade studies. Overcoming 
these challenges is an on-going effort in some cases while 
others were conquered easily once examined through a systems 
engineering approach. These challenges resulted in the 
following lessons learned and recommendations to be followed 
when completing similar exercises in the future. 

• Plan to achieve efficient maintainability & 
sustainability: Efficient maintenance of software 
intensive systems is significantly different than of 
hardware based systems. How the software systems are 
developed has a major impact on how easily and 
efficiently they can be maintained. When transitioning 
from a hardware based system to a software intensive 
system, it is important that management and 
maintenance engineers be made aware of the risks and 
challenges inherent within these systems so that proper 
steps can be taken to minimize the tendency patch the 
software in a way that does not allow for major 
upgrades or improvements in the future. 

• Lack of source code and documentation can present 
long term sustainability issues: The use of small 

businesses or outside vendors to develop software can 
pose risks to the development and maintenance of 
software based systems. These risks can have been 
mitigated to an extent by taking steps such as proper 
software documentation (including valuable and 
extensive commenting and maintainable and readable 
code structure), and acquiring vendor source code. 
Although the acquisition of source code is typically a 
large financial commitment, being able to maintain and 


sustain source code in a flexible (using in-house 
workers or vendors) and timely manner can reduce 
costs in a way that justifies the up-front costs. There 
will always be a certain amount of risk though due to 
the lack of familiarity with the externally-developed 
system by NASA employees and operators. 

• Choose integration steps wisely: When integrating 
legacy systems it is important to define what level of 
integration is technically feasible and within the budget, 
so that time and energy can be focused on the 
achievement of the most impactful integration rather 
than figuring out how to integrate every last detail of 
systems that may benefit from some level of difference. 

• Implement enabling processes: Because SCaN is 
attempting to transition to a more service-oriented 
organization that offers standardized services, it is 
important to put into place constructs and processes 
which facilitate this change. Therefore, every request 
for a new service must be processed in a way that 
determines exactly what is different about the newly 
proposed service and if that service can be implemented 
in a way that it will meet the needs of multiple different 
user missions. 

• Beware of preconceived notions and resistance to 
change: It is easy to have preconceived notions of what 
is possible and impossible, especially with respect to 
the level of automation that can be allowed within a 
system. In this respect, having intimate knowledge of 
one or more operational systems within a trade space 
can have both advantages and disadvantages. If 
someone has operated a given system in the as-is state, 
it could be difficult for that individual to envision that 
system becoming so automated that a particular 
operational role no longer consumes all of one person’s 
attention. If the goal is to determine what the limits of 
potential automation are within a system, it is important 
to work not only with personnel who understand the 
legacy systems very well, but also others who lack that 
intimate knowledge of the system of interest and who 
have knowledge of cutting edge solutions that could 
apply. 

• Balance innovation and cost: Innovation and 

increasing levels of automation are often very appealing 
to engineers who continually strive to make their 
system of interest more efficient and would enjoy 
implementing the latest and greatest technology. When 
dealing with systems-of-systems the desire to make the 
system as innovative as possible must be balanced 
against technical risks and implementation costs. The 
realization of a moderate improvement in automation 
and system innovation that can actually be implemented 
may be better than striving for the most innovative 
solution, particularly if that solution is too costly to 
implement. 

• Common processes and ease of access to information 
can have a positive impact: The SCaN service 
planning process is very manual and communication 



intensive. There are two aspects of this process which 
may be improved: the interaction between SCaN and 
the user mission, and the interactions across the existing 
organizations and networks within the SCaN Program. 
Both interfaces could benefit from the implementation 
of additional tools and standardized processes. The need 
for interaction between SCaN personnel and user 
missions will never be eliminated. It may be possible, 
however, to make the process more efficient through 
the implementation of standardized processes and tools 
which make communication between the two parties 
easier, the dissemination of information more efficient, 
and streamline the generation of different forms of 
documentation. A user guide that describes all aspects 
of the planning process to the user missions and walks 
them through all the steps they must complete has been 
identified as an essential part of these new tools. This 
user guide, along with consolidation of reference 
information is expected to go a long way to making the 
service planning process more efficient from the user 
mission perspective. 

When in doubt, prove whether or not something is 
possible or impossible to do: It would be invaluable to 
do a process study to determine whether or not 
individuals could be hired and trained in the operational 
of multiple different networks within SCaN. This type 
of exercise would serve to prove out the assertions that 
the next generation of employees could be trained to 
support multiple networks as well as aid in the 
identification of what types of automation and 
innovation within the systems would make the cross 
support process more efficient. This study could be 
performed through examination of the capabilities of 
space communications and navigation systems outside 
of NASA which were implemented more recently. If no 
equivalent systems exist, an in-house study could be 
performed where potential new employees, or existing 
employees are given the opportunity to learn more than 
one system and their experiences are used to quantify 
the potential challenges of cross training. 

Quantifiable proof in studies is invaluable: When 
evaluating potential new solutions to existing 
challenges it is extremely important to gather 
quantifiable proof as to whether new and innovative 
solutions can or cannot be implemented. Without this 
vetting process, high value solutions may be discarded 
early on due to preconceived notions about what is 
possible and impossible within existing operational 
systems. 

Terminology and common understanding cannot be 
assumed or over emphasized: Even when team 
members all work in the same domain, understanding 
exactly what each other is saying is of utmost 
importance. Throughout the course of the trade studies 
there were numerous occasions where a term common 
to the space communications domain would be used 
and everyone would think that they knew what the 
person talking was referring to; but when the idea was 
driven to the next level of detail we would find out that 


at least two people (often more) on the team had a 
slightly different interpretation of that same term. The 
creation of a common glossary to ensure the trade study 
team was on the same page proved invaluable. 

• Understand your team and managements so you can 
work with them to minimize the resistance to 
change: Including leaders from within the existing 
operational systems as decisions makers within the 
trade study review process is a precarious undertaking. 
Often times these leaders are concerned with the 
potential negative impacts to their system as opposed to 
seeing the overall benefit to the system of systems. To 
ensure these leaders can be productively involved in the 
process of making changes which impact the system-of- 
systems, it is important those involved in the definition 
of potential options are not only fully educated in the 
existing systems, but educated in the user missions’ 
needs and concerns as well. Without proving an in- 
depth understanding of the current system, the 
organization’s needs and their user mission needs, it 
may be impossible to convince leaders within an 
organization that change is a good thing. Quantifiable 
financial benefit paired with an in-depth understanding 
of the value provided by the existing system and the 
impacts of its’ modification on the systems of systems 
is often the best way to convince leaders that major 
changes to the system would be beneficial. 

• Collaboration and consensus doesn't always mean 
that everyone agrees that there is only one right 
answer: NASA’s culture values decision making by 
consensus very highly. When decision makers have a 
vested interest in the existing system it is often 
impossible to bring everyone into agreement that there 
is one best solution to the problem. It is important to 
remember the consensus doesn’t mean everyone 
agreeing to a single idea; instead it means that everyone 
has the opportunity to voice their opinion and 
understand the proposed solution well enough to stand 
behind it. Coming to the point where everyone, even 
those who prefer other solutions, can stand behind a 
decision is of great importance when making decisions 
that will take years to implement. 

IV. Conclusion 

These are just a few of the technical and cultural challenges 
facing SCaN’s goal of integrating the networks to increase 
efficiency and ease of use for its user missions. The cultural 
challenges present are as equally daunting an obstacle as any of 
the technical challenges, not only because the technical 
challenges have been proven to be conquerable, but because 
the cultural differences between the networks and network 
personnel has been growing since the birth of the networks. 
These deep-seated philosophies of how the networks must be 
operated need to be tempered with reasoned new ideas and 
approaches in order to realize a maximally integrated network. 
The trade studies team found that applying quantitative 
systems engineering processes was advantageous in 
overcoming the resistance to change and differing perceptions 
on what level of change could be implemented. 
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